Repository navigation
topology2: alh: add tuple_values for the direction attribute - #11412
Conversation
|
This fixes SOF build with upstream alsa-lib. @ujfalusi and @bardliao I do wonder should we alternatively drop the direction value for ALH. Based on my analysis, it is not really used by the kernel, which explains why the wrong values in existing topologies have not caused any bad outcomes. My checks so far from kernel source:
So as an alternative to this PR, we could also drop "dai.word" from ALH. Let me know what you think. |
There was a problem hiding this comment.
Warning
Copilot couldn't run its full agentic review because it didn't start before the timeout. Make sure your repository has a runner available, or add a copilot-code-review.yml file specifying one with the runs-on attribute. See the docs for more details.
Copilot review overview
No open issues 🎉
What changed in this PR
Adds an explicit tuple_values mapping for the ALH DAI direction attribute so string tokens (playback/capture/duplex) are encoded as numeric tuple values and don’t fail parsing on newer alsa-lib.
Changes:
- Add
!tuple_valuesfor ALHdirectionto map direction strings to numeric values (0/1/2).
| File | Description |
|---|---|
| tools/topology/topology2/include/dais/alh.conf | Adds tuple_values mapping for direction to ensure topology tuple encoding works with stricter alsa-lib parsing |
Review effort: Lite
PR 11412: test resultsRun date: 2026-11-09 11:56 UTC Tested commit: 4bbf0eb5b244d2cecefa9ca11d94895a53b287fc
|
|
@kv2019i It looks all DAI have the direction attribute. I will not suggest removing it. Can we remove |
c63b640 to
4bbf0eb
Compare
|
@bardliao wrote:
Ok, this is better idea. Seems this is safe w.r.t. old kernels, decoded binaries benefit from extra readability and SOF can be built with upstream alsa-lib (again). V2 pushed. |
The ALH DAI class defines "direction" as a string attribute with
token_ref "dai.word", but without a tuple_values mapping. As a result
the string values "playback"/"capture" end up verbatim in a word tuple.
Older alsa-lib converted such strings with strtoul() and silently
encoded them as 0 (so capture links were also encoded as 0). Since
alsa-lib commit c41be26af2d9 ("topology: use snd_config_get_llong() in
tplg_get_integer/unsigned()"), non-numeric strings are rejected and
the build of e.g. cavs-sdw.tplg fails with:
ALSA lib data.c:866:(parse_tuple_set) [error.topology] tuple direction: Invalid argument
The direction tuple ends up in the BE link private data. The Linux SOF
driver has never parsed SOF_TKN_DAI_DIRECTION from link data (only from
DAI widget data), in neither the pre-5.19 sof_parse_token_sets() nor
the current sof_copy_tuples() based code, and both silently skip
unknown tokens. Changing the tuple type is thus safe for old and new
kernels.
Switch the token_ref to "dai.string" so the direction is passed as a
string tuple.
Link: alsa-project/alsa-lib@c41be26
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
4bbf0eb to
b5b40d8
Compare
|
V3:
|
|
Topologies not tested by the one CI Intel check that is still pending (and seems to be stuck). Bypassing and proceeding with merge. |
The ALH DAI class defines "direction" as a string attribute with token_ref "dai.word", but lacks the tuple_values mapping that other classes (dai, dai-copier, host-copier) use. As a result the string values "playback"/"capture" end up verbatim in a word tuple.
Older alsa-lib converted such strings with strtoul() and silently encoded them as 0 (so capture links were also encoded as 0). Since alsa-lib commit c41be26af2d9 ("topology: use snd_config_get_llong() in tplg_get_integer/unsigned()"), non-numeric strings are rejected and the build of e.g. cavs-sdw.tplg fails with:
ALSA lib data.c:866:(parse_tuple_set) [error.topology] tuple direction: Invalid argument
Add tuple_values to map the direction strings to numeric values.
Link: alsa-project/alsa-lib@c41be26